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ABSTRACT 



A system and method for controlling duplicate transaction 
submission in a web browser/web server environment. The 
client web browser is modified to include a process duplicate 
action select (e.g. duplicate mouse "clicks") detection. This 
process establishes a variable for an action indicating 
whether the action has been previously selected. Upon 
selection, the process tests the action variable and passes the 
transaction request if not previously submitted and returns 
an error otherwise. The server process has been augmented 
.with a duplicate transaction process. The server software 
inserts a _tranid parameter into each of a plurality of 
selected pages returned to a browser for transaction process- 
ing. The server maintains a record of the last used jranid. The 
server compares a tranid returned in a user request to the 
recorded value. If previously processed, an error is returned 
to the requester. If not previously processed, the recorded 
"last transaction id" is updated and the request fulfilled. 

18 Claims, 4 Drawing Sheets 
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This processing occurs on the web server when a user 
requests a page in order to perform a transaction. For 
example, when the user clicks on a 1 want to do 
transfer* icon, the server will build a transfer request 
page that the user can fill in with data. Part of building 
that page is to get a new transaction id (tranid) and put 
it into 'do the transfer' URL 



FIG. 4 
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This routine executes when a user 
submits a request to the web server. It 
checks if the transaction identified by the 

tranid has been processed before. If 
not, the request is processed. If so, the 
request is not done a second time. The 
processing in the box is contained in the 
CheckDupTran function. 
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SYSTEM AND METHOD FOR PREVENTING then clicks on the browser 'reload' button (called 'refresh* in 

DUPLICATE TRANSACTIONS IN AN the Internet Explorer browser). Clicking the reload button 

INTERNET BROWSER/INTERNET SERVER causes the transaction to be sent to the web server a second 

ENVIRONMENT lime. 

5 3. Enter-Stop-Enter: The user submits a transaction by 

BACKGROUND OF THE INVENTION clicking on an enter button. While waiting for the response 

1. Field of the Invention lne user clicks the browser 'stop' button and the clicks the 

.... i. . t enter button again. Clicking the enter button the second time 

Fne present invention relates to computer processor ..... . ^ . j 

■ i at Ji n1 „ r i „„™„:„„ * tor Z- submits the transaction to the web server a second time. 

implemented transaction processing systems. More 10 

particularly, the present invention relates to transaction 4 - Multiple-Clicks: If a user clicks multiple times on an 

control mechanisms for ensuring the reliability and integrity enter button » browsers may submit multiple identical trans- 

of transactions processed in an on-line transaction process- actions to the web server. The behavior of the browsers 

ing system. Still more particularly, the present invention differs based u P° n which browser is used (Netscape Navi- 

relates to transaction processing over the Internet using 6 ator ^ different than Microsoft Internet Explorer), the 

Internet browsers and Internet servers to process on-line HTML ^ of the enter button, and how many clicks were 

transactions. e n t ered • 

2. Background and Related Art 5 - Resize: Resizing the browser window may, in some 

n t „„ c „ t :„„ npA ^ ff ; nrt «,et„ m * instances, cause the browser to reload the transaction in the 

Computer implemented transaction processing systems , . , 

browser window 

are used to manage information collected and used by 20 

businesses worldwide. Historically, transaction processing * EacD of lhesc situations results in an undesirable dupli- 
has been used by banks and airlines to handle customer cation of transaction processing. A technical problem there- 
transactions. In both of these industries, the accuracy of the fore exists to prevent duplicate transaction processing in a 
data is a prime concern. Transaction processing systems browser/server environment, 
have been designed" to ensure that data is properly updated 25 
and that any failure of the system is handled in a predictable 
and recoverable manner. The present invention solves the duplicate transaction 
The widespread implementation of Internet technology processing in a browser/server environment by implement - 
has created a demand to enable consumers to directly enter ing checks on both the client browser side and server side of 
transactions with their banks and to make reservations with 30 the transaction. Client programs running on the browser are 
travel companies. Implementation of client driven transac- be restructured to eliminate duplicate transaction submis- 
tion processing systems must meet the high data integrity " sion. Server systems are assembled to track form submission 
requirements consumers expect. For example, consumer use and to reject any duplicate forms, 
of an Internet banking program to transfer funds must result [claim language] 

in the funds either being fully transferred into the correct 35 u ^ therefore an object of the invention to eliminate 

account, or the transaction being terminated with a reported duplicate transaction submission in a browser/server envi- 

error - ronment. 

The problem of duplicate transaction entry is of particular , t fe t anolher object of lhe invention t0 preven t dupli- 

interest The processing system must ensure that a specific cate processmg of a tranS action submitted from a browser, 

transaction is processed once and only once. Unfortunately, ^ . , , - , , 

Internet browser, technology makes duplicate transaction ™ e fore &°. in S ° lher ° b J ects > features and advantages 

entry relatively common. Internet browsers have been devel- of he ™'° Uoa . ™ U be W™ 0 fro f th ? f ° Uowm & ™ re 

oped to access and view data over the worldwide web. .P^icular descnpt.on of a preferred embodiment of the 

,f. , ~ . . j , 11 . invention, as illustrated in the accompanying drawing 

Viewing and even non- financial data entry are usually not , . ' r . * i*i — . 

u j l j r . . . ■ ■ r . . , 45 wherein like reference numbers represent like parts of the 

harmed by duplicate transaction submissions. Financial . . r r 

transactions cannot tolerate duplicate entries. invention. 

Duplicate transactions occur, in part, because of the BRIEF DESCRIPTION OF THE DRAWING 
stateless nature of browser/server applications. The server 

supplies a "web page" to the client browser for action by the cn FIG * 1 15 a block dia g ram Crating the computer 

user. The prior art servers do not retain any state information 50 environment of the preferred embodiment of the present 

about the form supplied. When the browser submits the invention. 

form, it is acted upon by the server, again without monitor- FIG- 2 is a block diagram of a computer system according 

ing the previous state of the application. The user can cause to the present invention. 

the same form to be submitted a second time without the JS . FIG. 3 is a flow chart of the process of client side 

server detecting the duplication. duplicate action selection detection according to the present 

Browser technology allows the following types of dupli- invention, 

cate transaction entries to occur. Note that the 'enter 1 button FIG. 4 is a flow chart of the process of server side 

in the following items denotes the page element that the user transaction sequence number assignment according to the 

clicks on to submit a transaction. It could be a form submit 60 present invention. 

button, a form image button, or an HREF. FIG. 5 is a flow chart of the process of server side 
_L _ BnlerrBac^EDterThe'user : submits., a Jransaction-by^ duplicate transaction detection according to the present 

clicking on an enter button. The user seesthe responserLaterj invention, 
r- the-userjtses the browser-s-back-button taback upJnto^Uie 

^previously submitted transaction and cliclcson enter again 65 DETAILED DESCRIPTION 

2. Enter-Reload: Here the user submits a transaction by Internet applications are implemented with a client 

clicking on an enter button. The user sees the response and "browser" for user interaction and a server for application 
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processing. The client browser is graphically oriented and 
presents a graphical page of data (or screen) to the user for 
action. Cjataj^agrfreie^ 
can-be-requestcdJ}y_cHcking-a-^ 

roo^TOn^ap action "button"^ onspecially defined" fields 5 
on-the-screen. ^ 

Internet servers process requests submitted by the brows- 
ers. Servers locate and present requested data to the user 
using forms defined according to the HyperText Markup 
Language standard (HTML.) This standard defines the con- 10 
tent of a form to be displayed by the browser and the actions 
the user will be permitted to take. The server and browser 
software need not be from the same vendor. Servers must be 
responsive to any valid HTML request from a browser and 
browsers must be responsive to server generated forms. 35 
Internet server software is marketed and sold by Netscape 
Communications Corp., IBM Corp., Microsoft Corp. and 
others. Browser software is available from these and other 
vendors. 

Application logic is typically stored in the server and 
executed in response to a browser request Some logic, 
however, can be downloaded to the client browser as a part 
of the form to be' executed in response to a user action. This 
logic is typically coded in the JavaScript interpretive lan- 
guage developed by Netscape Communications Corp. Java- 
Script implements programming statements that permit cli- 
ent based action processing. 

The present invention is implemented in an Internet or 
Intranet (within one organization) system such as that shown 
in FIG. 1. Any number of client workstations with browser 
software 102, 104 are connected through a network 106 to 
an Internet server 108 running server software. The network 
106 can be any of a variety of known or to be developed 
local area network or wide area network topologies. 

The client and server computer systems will be similar to 
that illustrated generally in FIG. 2 at 200. It will have a 
processing unit 202 with one or more central processing 
units (CPUs) connected through a system bus 206 to random 
access memory 204. Network controller 208 controls data 
exchange over the network. Input/output controller 210 
manages interaction with fixed storage 212, removable 
storage 214 and user input devices such as keyboard 216, 
pointing device 218 and display monitor 220. The preferred 




20 



25 



30 



the_sexvef~~for; 



action r 

:cause-a-re que5Uioi?e-seaMo-a 

'eTare: 

^DA FORM with an input type-submit button. 
<FORM METHOD-. . . > 
< INPUT TYPE-"submif value-"Enter"> 
^?A FORM with an input type«image button 
<FORM METHOD-. . . > 
<INPUT TYPE-"image" SRC»"enter.gif *> 

A text HREF. 
<A HREF="pageref.html?parms=xxx"> 
Click Here To Submit Transaction. 
</A> 

a4\ An image HREF. 
<A HREF-"pageref .html?parms-xxx"> 
<IMG SRC«"enter.gif '> 
</A> 

4$3!!uiseT?<dieksi^^ 
brows^g^jyil ^ejid^ a^eq ^ 

However, a browser's response to a user double clicking or 
triple clicking on the above types is different based on type. 

The following Table 1 shows how the Netscape Navigator 
3, Microsoft IE 3.02, and Netscape Communicator 4 brows- 
ers react when a user double clicks on the various page 
elements. 

TABLE 1 



Page 

Reference 
Type 



NS Navigator 
3 



MS IE 3.02 



NS 

Communicator 
4.01a 



TYPE = 


2 Transactions . 


2 Transactions 


Usually 1 


"submit" 






TYPE - 


Usually 1 


Usually 1 


Usually 1 


"image" • 








Text HREF 


Occasionally 2 


Usually 1 


Usually 1 


Image HREF 


Ocassionally 2 


Usually 1 


Usually 1 



40 



The term 'usually 1' indicates that most of the time 
(greater than 95% in the authors testing) only a single 
transaction is sent to the web server. The term 'occasionally 



V means that the majority of the time (>50%) only a single 
embodiment employs and IBM Personal Computer as the 45 transaction was sent. However, depending upon the speed at 



client computer and an IBM RS/6000 workstation as the 
server computer. The invention is not limited, however, to 
any particular computer type or configuration, except as 
specified in the claims. 

The preferred embodiment solves the duplicate transac- 
tion problem by first eliminating duplicate transaction sub- 
mission on the client side where possible, and avoiding 
duplicate transaction processing on the server side in all 
cases. Avoiding duplicate submission' is desirable even when 



which the double click was done, the author could get 2 
transactions sent more ofien than the 'usually 1' case. 

The situation changes when the user triple clicks on the 
page elements. Often one would see 2 transactions submit- 
ted in this case. 

The Netscape JavaScript language includes features that 
enable JavaScript logic to be executed whenever the user 
clicks on a page element. The JavaScript event handlers get 
control whenever a user clicks on a page element. The 



duplicate processing is avoided due to the elimination of the 55 present invention is directed to a novel structure of computer 

network traffic associated with the duplicate submission. readable program code that causes an event handler to 

TlieTchent^ia^^lutiWis based on monitoring transaction prevent the browser from submitting multiple transactions 

subrmssipn'realiests and detectmg duphca^ when the user clicks multiple times on a page element, 

embodimenris implelnented'as^ The method for intercepting page element events differs 

c^ahputine to examine tfa^s^tion submission. A description 60 between the types of page elements. The <FORM> page 

of client side submission processing is necessary before element enables an "onSubmit" Javascript event handler 

describing the preferred embodiment in detail. routine to be specified. The routine will be called 

^ pl&gi^IgSgg^ u checkIfSubmitted( )" This looks like: 

HT^jfolm^e^^ <FORM METHOD-. . . onSubmit»"return 

l^HTO inaflguage-spe ctfiesxertai Di^^ check!fSubmitted( )"> 

rnllfiSg^a torm or-lrasacQon back-to the server, ^ubmisslofp The HREF page elements enables an "onClick" Javascript 

anrces:tbexlielit:b76w^ event handler routine to be specified. 
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<A HREF-"page^ef.btml?parms*xxx ,, onclick-"return building the page for transmission to the client requests a 

check! fSu bmittedf Y*> lim L mtt gl „ , m tranid using a GetNewDupTran( ) function 402. This func- 

^bcichesKitou^^rtean^ tion is written in JavaScript in the preferred embodiment and 
pg^TjftproMkiedwb^tbc^pa1gey<kyeloper^ F6Ubwmg~is~a~ maintains the assigned number sequence. A „tranid history 

checklf$ubmitted( ) Javascript event handler according to 5 is maintained for each client (user). The tranid is inserted 

the present invention: into the URL for the page and the page returned to the user 

404. 

Server side duplicate detection is performed using the 
—————— CheckDupTran( ) procedure. CheckDupTran( ) compares 

<SCRIPT> the tranid returned by a form to the sequence maintained at 

var^bmi^onn--yes" ; the and s{ h aQ efror whenever lhe comparison 

function checklfSubmioed 0 { • j- . , ,. . . . . ™ t . , r 

if (submitFonn— "yes") { indicates duplicate submission. The two server side proce- 

submitForm-"no"; dures are described below. 

return(truc); } GetNewDupTran( ): This function returns a character 

clse { . string tranid for a new transaction. This string must be put 

retum(faisc); } 15 into a _tranid parameter in the URL. 

</scrift> CheckDupTran( ): This function compares a tranid 

obtained from lhe URL __tranid parameter and atomically 
compares it to the last completed transaction tranid from this 

The use of onsubmit and onClick event handlers prevents user. If the URL _tranid.is greater than last completed 

duplicate transactions from being submitted on multiple 20 transaction tranid, then the function makes URL _tranid the 

clicks by the Netscape Navigator 3 and Communicator 4 . last completed transaction tranid and returns a value of 0. 

browsers. Otherwise, the transaction represented by request._tranid is 

However, the Internet Explorer 3.02 browser only recog- a duplicate transaction and the function returns a non-zero 

nizes the onSubmit event handler on the FORM type-submit value. 

page reference type. IE 3.02 ignores the onSubmit event 25 In lne preferred embodiment, the above routines are 

handler on the FORM type=image reference and the onClick written as C language programs that can be invoked from 

event handler on HREF references. Fortunately, IE 3.02 does JavaScript. The C language routines implement the tracking 

not frequently send multiple transactions on the page refer- of transaction sequence number values and transaction 

ence types on which it ignores the event handler. slales ;. In ^*°\^ y ™. 10 P erform the ™ m P* re 

Jbctfmessrfaw^^ 30 0 I* ratl0ns : ™ osc sk ^ 10 the art ^ rccogaizc that other 

— Trr^i — r — r~z — „ . r „ , ~ functions without departing from the invention. 

variable^submitform is-set-toz^ves-_r302^Whenrthe"tiser m. r... . • _* j • , c 

"-f ; * . " " , The server software must insert a tranid in each form 

xlicks-a^select-button 304:me^JavaScTrpt r checks r whether:the> j . *u r • u -ru . -a u * j 

^ — rrr " . ~ . * „ Tt« „ . , . ^ send to the client browser. The _tranid can be inserted as a 

v ^ ab le. submit Form-is _!yes~306.~I f — y es'^the subm i t Fo rm . • . „,„ m(ltor - t . ~ m ^ r _ ^ „,.,, • UDRn 

■ — ■ ~r~ — « ». . . . -— T -, hidden parameter in the torm or as a vanable in an HRLr 

variable_is,set to^noUand4he-request-sent-tO"the server. If 35 t t ' t t,. c „ , . , 
C-.~ -v — ~~ „~r - v . . . , statement. The following demonstrates how 
submitForm-i s^no^the ^userrselecUon-is^ignoreQ^and^no r--»M ,n t / \ ■ . • . . T . t 4 
, _ - — , GetNewDupTranf ) is used in server side Javascript to put 

Z__^r— A . . , the _jranid parameter variable as a hidden parameter in a 

Server side duplicate transaction processing is required to <FORM>* 

ensure that duplicate transactions are not entered in spite of . /( Pnnvf v*PTTinn ^ 

multiple click detection on the client. The client browser 40 '™*J , ZJ v T . ^ 

user can cause a duplicate transaction to be submitted in w "' e < T^™' NAME-"_lranid" 

other ways. DupUcate detection on the server side is based +GetNewDupTran( )+'>'); 

on a transaction sequence number ("tranid"). ™ e followm e demonstrates how GetNewDupTran( ) is 

A transaction sequence number is assigned to each form - used t0 ^ the - tramd P a ' a ™ter on a HREF, 

sent to the browser for processing. The server detects any 45 wnte('<A HREF«"pageref.html?_tranid = ' + 

duplicate submission of a form containing a particular GetNewDupTran( )+*>'); 

transaction sequence number. The server side detection logic writeC Click Here To Submit Transaction/); 

includes the following steps: write('</A>'); 

1. The tranid of the last completed transaction for the user The following demonstrates how CheckDupTran( ) is 
is saved in the web server. 50 used to check whether a transaction is a duplicate. The 

2. Pages that contain a page reference link which can following examples are based on an embodiment used by a 
submit a transaction must contain a tranid. The page must bank to process banking transactions. The example assumes 
obtain a new tranid to put into the reference link. This new a bank wants to redirect processing to a page called duper- 
tranid must be larger than the last completed transaction r.html in the event a duplicate transaction is detected, 
tranid saved in the web server. 55 if (CheckDupTran( )!»0) 

3. When a page gets control to submit a transaction, the redirect (addChentO duperr.html')); 

page must compare the tranid passed in the reference link to The server side bank page customizer is responsible for 

the tranid of the last completed transaction. If the tranid in getting the _tranid into the request URLs and putting the 

the reference link is greater than last completed transaction CheckDupTran( ) into the appropriate page execution paths, 

tranid, then this is. a new request from the user. The tranid 60 A bank can select which transactions it wants to check for 

from the reference is put into the last completed transaction duplicates. A bank may not care if duplicate inquiry type 

tranid and the user's transaction is processed. If the tranid in transactions are sent by a user. Additionally, navigation type 

the reference is less than or equal to the last completed URLs (such as those associated with icons across the top of 

transaction tranid, then the user's request is a duplicate and a page) must not have duplicate checking done in their 

should not be processed again. 65 execution paths. (If this was done, clicking the navigation 

Obtaining a tranid for a page and adding it to the page button a second time would cause a duplicate transaction to 

follows the process illustrated in FIG. 4. The server program * be detected.) 
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Server side duplicate transaction detection code must 
cause a response to be sent back to the user telling the user 
that a duplicate transaction has been detected The user needs 
to be told: 

1. What happened? 5 

2. Was the duplicate transaction processed (Was it sent to 
the bank)? 

3. What caused the problem? 

4. What can user do to avoid the problem? 

5. How does the user continue the banking session? 
Following is an example response which attempts to 

answer the above questions: 

"You submitted a transaction which is a duplicate of a 
previous transaction. The duplicate transaction has not been 
processed. You may have caused the duplicate transaction by 
one of the following actions: 15 

Using the browser "Back" button and submitting a trans- 
action. 

Using the browser "Reload" or "Refresh" button. 

Using the browser "Stop" button and submitting a trans- 
action. 20 

Double mouse clicking when submitting a transaction. 

You can avoid submitting duplicate transactions by using 
the navigation links provided on the banking pages. Avoid 
the use of the browser 'back', 'stop* and Reload' buttons 
during a banking session. Click your mouse only once when 2 s 
you submit a transaction. 

You may continue your banking session by clicking a 
navigation link on this page." 

The server side processing is illustrated in FIGS. 4 and 5. 
FIG. illustrates the process flow for inserting a _tranid into 3Q 
a URL. The server side process acquires a new tranid by 
invoking the GetNewDupTran( ) process 402. This tranid is 
inserted into the URL and the page returned to the user 404. 

FIG. 5 illustrates the process of duplicate detection. The 
server process starts at 502 and receives a user request with ^ 
a returned page containing a _tranid 503. The server checks 
whether this _tranid has been previously processed 504 
using, for example, a routine such as CheckDupTran( ). If he 
tranid was previously processed, a "duplicate transaction" 
message is returned to the user 506 and processing tcrmi- ^ 
nates. If the tranid has not been processed, the tranid is saved 
as having been processed 507 and the user request in the 
transaction is processed 508. 

It will be understood from the foregoing description that 
various modifications and changes may be made in the ^ 
preferred embodiment of the present invention without 
departing from its true spirit. It is intended that this descrip- 
tion is for purposes of illustration only and should not be 
construed in a limiting sense. The scope of this invention 
should be limited only by the language of the following 
claims. 

What is claimed is: 

1. A computer implemented method for eliminating dupli- 
cate request submission from a browser to a server in a 
browser/server environment, the browser operating on a 
client computer processor having client memory and client 
processing means, the method comprising the steps of: 
setting an indicator to a first state in the client memory; 
detecting a request submission at the client to send a 

request to the server; testing said indicator, and 60 
if said indicator is set to said first state, then submitting the 
request to the server, and resetting the indicator to a 
second state, 

if said indicator is set to said second state, ignoring the 
request submission and raising an error condition; 65 

thereby reducing network traffic associated with duplicate 
request submissions. 
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2. The method of claim 1, wherein said detecting step 
detects the request submission bv a pointing device means 
selection of an HTTP FORM "submit" button. 

3. The method of claim 1, wherein said detecting step 
detects the request submission by a pointing device means 
selection of an HTTP HREF selection. 

4. A computer implemented method for avoiding dupli- 
cate transaction entry in a browser client/server 
environment, the method comprising the steps of: 

detecting duplicate submission requests at said client and 
not submitting said duplicate submission requests to 
the server thereby reducing network traffic associated 
with duplicate request submissions; 

detecting duplicate submitted transactions at said server 
and rejecting said duplicates. 

5. The method of claim 4, wherein said detecting dupli- 
cate submission requests at said client comprises the steps 
of: 

setting an indicator to a first state in a client memory; 
detecting a request submission at the client to send a 

request to the server; 
testing said indicator, and 

if said indicator is set to said first state, then submitting the 
request to the server, and resetting the indicator to a 
second state, 

if said indicator is set to said second state, ignoring the 
request submission and raising an error condition. 

6. The method of claim 5, wherein said detecting dupli- 
cate submitted transactions at the server comprises the steps 
of: 

setting a unique transaction identifier for a form in a web 

page returned to said setting a unique transaction client 

to begin a transaction; 
receiving a submitted request including said form and 

returned transaction identifier; 
testing said returned transaction identifier to determine 

whether or not said .transaction identifier has been 

previously returned; 
if previously returned, raising an error condition. 

7. The method of claim 6, wherein said transaction 
identifier is a numeric sequence number and wherein said 
process maintains in a memory means a value of the highest 
returned transaction identifier, and wherein said testing said 
returned transaction identifier tests said returned identifier 
against said maintained value. 

8. The method of claim 4, wherein said detecting dupli- 
cate submitted transactions at the server comprises the steps 
of: 

setting a unique transaction identifier for a form in a web 

page returned to said client to begin a transaction; 
receiving a submitted request including said form and 

returned transaction identifier; 
testing said returned transaction identifier to determine 

whether or not said transaction identifier has been 

previously returned; 
if not previously returned, performing said requested 

transaction and setting said transaction identifier as 

being returned; 
if previously returned, raising an error condition. 

9. A client computer system for avoiding duplicate trans- 
• action processing in browser/server environment, the system 

comprising: 

client memory means for storing an indicator of browser 
request submission; 
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client processing means for detecting a request to submit 

a browser request to a server; 
client processing means for testing said indicator to 

determine whether said request has been previously 

submitted; 

client response means for raising an error condition and 
ignoring said request if said test determines the request 
was previously submitted; and 

client processing means for submitting said requested 
request and setting said indicator to indicate 
submission, if said request was not previously submit- 
ted; and 

thereby reducing network traffic associated with duplicate 
request submissions. 

10. A web server for detecting duplicate transaction 
requests in a stateless web server environment, said web 
server having memory means and processing means, the 
system comprising: 

means for assigning a unique identifier to a form; 

means for sending the unique identifier in a web page to 
the browser client; 

means for receiving a browser request for a transaction 
including said unique identifier; 

means for testing said unique identifier to determine 
whether or not a transaction having said unique iden- 
tifier has been processed; 

means for processing said request of said unique identifier 
has not been previously processed, said means for 
processing setting an indicator that said unique identi- 
fier has been processed; and 

means for raising an error condition if said unique iden- 
tifier has been processed. 

11. The system of claim 10, wherein said means for 35 
assigning a unique identifier includes: 

means for requesting a unique identifier; and 
means for inserting said unique identifier in an form 
definition in the web page. 

12. The system of claim 11, wherein said form definition 40 
is in Hypertext Markup Protocol (HTTP) form and said 
inserting adds said unique identifier as a hidden variable. 

13. The system of claim 11, wherein said form definition 
is in Hypertext Markup Protocol (HTTP) form and said 
inserting adds said unique identifier as an HREF URL 
variable. 

14. A computer program product having a computer 
readable medium having computer program logic recorded 
thereon for avoiding duplicate transactions in a browser/ 
server computer system, said computer program product 
comprising: 

computer program product means for causing a client 
computer system to detect a browser request submis- 
sion; 
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computer program product means for causing the client 
computer system to determine whether said request has 
been previously submitted; 

computer program product means for causing the client 
computer to reject said requested submission is not 
previously submitted or returning an error if previously 
submitted; 

thereby reducing network traffic associated with duplicate 
request transmissions. 

15. The computer program product of claim 14, wherein 
said computer program product means for causing a com- 
puter to detect a browser request submission comprises: 

computer program product means for causing a computer 
to detect pointing device activation of an HTTP "sub- 
mit" field. 

16. The computer program product of claim 14, wherein 
said computer program product means for causing a com- 
puter to detect a browser request submission comprises: 

computer program product means for causing a computer 
to detect pointing device activation of an HTTP hyper- 
text link "HREF" field. 

17. The computer program product of claim 14, wherein 
said computer program product means for causing a com- 
puter to test said unique identifier comprises: 

computer program product means for causing a computer 
to store a value of said highest unique identifier for a 
client; 

computer program product means for causing a computer 
to compare a returned unique identifier to said stored 
value. 

18. The computer program product of claim 14, further 
comprising: 

computer program product means for causing a server 
computer to assign a unique identifier for a transaction 
form and embed the unique identifier in a web page sent 
from the server computer to a browser in the client 
computer; 

computer program product means for causing a server 
computer to intercept a returned form from the client 
computer having the unique identifier; 

computer program product means for causing a server 
computer to test the unique identifier to determine 
whether or not the unique identifier has been previously 
submitted; and 

computer program product means for causing a server 
computer to reject said submitted transaction if previ- 
ously submitted or to process said transaction and 
update an indicator for the unique transaction identifier 
if the unique identifier has not been previously submit- 
ted. 
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